Processing Emergency Alert System Messages

ABSTRACT

Disclosed are methods and apparatus for processing an emergency alert message (e.g., a national warning system message e.g., an Emergency Alert System (EAS) message). The methods may comprise a digital media server receiving the message. The digital media server may notify client devices (that are connected to that server via a residential Local Area Network) that it has received such a message. The client devices notified may be those that have requested (e.g., to the digital media server) that they are notified if the digital media server receives such a message. The digital media server may convert the message from being in a first format to being in a second format. The digital media server may acquire, and provide for use by the client device, information that may be used a client device to ascertain whether the message is a new, an updated, or a duplicate message.

FIELD

The present invention relates to processing emergency alert messages,for example Emergency Alert System (EAS) messages.

BACKGROUND

Digital media servers (e.g., set-top boxes) in a home network (e.g., aresidential local area network) may support a national emergency alertsystem by presenting emergency alert information to client devices inthat home network. The servers in the home network may receive theemergency alert information from a multimedia service head-end.

Client devices (such as desktop computers, laptop computers, tabletcomputers, smartphones, set-top boxes, games consoles, etc.) may receiveemergency alert information via the home network. For example, DigitalLiving Network Alliance (DLNA) compliant Universal Plug and Play (UPnP)may be used by some media servers and client devices to distributeemergency alert system messages on the home network, thereby allowingpresentation of these messages to end users.

However, some servers and/or devices are incapable of using, or are notconfigured to use, DLNA compliant UPnP.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a schematic illustration (not to scale) of an example of anetwork for processing emergency alert messages;

FIG. 2 is a process flow chart showing a method of preparing a ContentDirectory Service;

FIG. 3 is a process flow chart showing a method by which a client devicemay subscribe to a service;

FIG. 4 is a process flow chart showing an example embodiment of aprocess by which an Emergency Alert Service message may be received by aserver, and by which client devices may be notified;

FIG. 5 is a process flow chart showing an example embodiment of aprocess which a client device may receive and display an Emergency AlertService message;

FIG. 6 is a process flow chart showing an example embodiment of a methodof preparing a server;

FIG. 7 is a process flow chart showing an example embodiment of a methodby which a client device may discover a server and request to benotified if that server receives an Emergency Alert Service message;

FIG. 8 is a process flow chart showing an example embodiment of aprocess by which an Emergency Alert Service message may be received by aserver, and by which client devices may be notified; and

FIGS. 9A and 9B are process flow charts showing an example embodiment ofa process by which an Emergency Alert Service message may be received bya server and displayed by a client device.

DETAILED DESCRIPTION

Embodiments disclosed herein provide methods and apparatuses forprocessing an emergency alert message (e.g., a national warning systemmessage such as an Emergency Alert System (EAS) message). The methodsmay include a digital media server receiving (e.g., from a serviceprovider) an emergency alert message. The digital media server maynotify client devices (that are connected to that server via aresidential Local Area Network) that it has received an emergency alertmessage. The client devices notified may be those that have requested(e.g., to the digital media server) that they are notified if thedigital media server receives an emergency alert message.

In some embodiments for processing an emergency alert message, themethods may comprise a digital media server receiving (e.g., from aservice provider) an emergency alert message. The digital media servermay convert the emergency alert message from being in a first format(e.g., a format that is not suitable for distribution to client deviceson a residential Local Area Network) to being in a second format (e.g.,a format that is suitable for distribution to client devices on aresidential Local Area Network). For example, an emergency alert messagein a first format that is compliant with the SCTE-18 standard may notsuitable for distribution to client devices. The digital media servermay convert the emergency alert messages to a second format, such as aformat that is compliant with the SCTE-162 standard.

In some embodiments for processing an emergency alert message, themethods may include a digital media server receiving (e.g., from aservice provider) an emergency alert message. The digital media servermay acquire (e.g., by processing or extracting from the receivedemergency alert message) information that may be used a client device toascertain whether the emergency alert message is a new message, anupdated message, or a duplicate message. The acquired information maythen be provided for use by the client device.

In some embodiments, the digital media server may subscribe a clientdevice to a service provided by that digital media server. The servicemay be such that, if the digital media server receives an emergencyalert message, the client device is notified that the digital mediaserver has received an emergency alert message. The method may includethe digital media server sending, to the client device, a servicemessage that indicates that the digital media server provides theservice. The digital media server may then receive (from the clientdevice) a request that the client device be subscribed to the service.The digital media server may then subscribe the client device to theservice.

In some embodiments, the digital media server may convert the emergencyalert message to be in a format that is suitable for distribution on theresidential Local Area Network. For example, the emergency alert messagemay be converted into an Extensible Markup Language (XML) format. Forexample, as described in more detail later below, the emergency alertmessage may be converted from being compliant with the SCTE-18 standardto being compliant with the SCTE-162 standard.

In some embodiments, the digital media server may provide, e.g., for useby the client device, the emergency alert message or a UniversalResource Locator that may be used the client device to retrieve theemergency alert message.

In some embodiments, the digital media server may provide, e.g., for useby the client device, information that may be used to ascertain whetherthe emergency alert message is a new message, an updated message, or aduplicate message.

In the following description, like reference numerals refer to likeelements.

The following description is based on embodiments of the invention andshould not be taken as limiting with regard to alternative embodimentsthat are not explicitly described herein.

An apparatus for implementing any of the below described arrangements,and performing any of the below described methods, may be provided byconfiguring or adapting any suitable apparatus, for example one or morecomputers or other processing apparatus or processors, and/or providingadditional modules. The apparatus may include a computer, a network ofcomputers, or one or more processors, for implementing instructions andusing data, including instructions and data in the form of a computerprogram or plurality of computer programs stored in or on a machinereadable storage medium such as computer memory, a computer disk, ROM,PROM etc., or any combination of these or other storage media.

It should be noted that certain of the processes depicted in the belowdescribed process flowcharts may be omitted or such processes may beperformed in an order different than that presented below and shown inthe process flowcharts. Furthermore, although all the processes have,for convenience and ease of understanding, been depicted as discrete andtemporally-sequential, nevertheless some of the processes may m fact beperformed simultaneously or at least overlapping to some extenttemporally.

Referring now to the Figures, FIG. 1 is a schematic illustration (not toscale) of an example of a network 1 in which embodiments of a method ofmay be implemented.

In the example network 1, a source of Emergency Alert System (EAS)messages (hereinafter referred to as an EAS source and indicated in FIG.1 by the reference numeral 2) may be connected to a service provider 4.An Emergency Alert System message may also be referred to as anEmergency Alert Service message, or an Emergency Alert Signallingmessage. Examples of the EAS sources include the National WeatherService of the United States of America, the Federal EmergencyManagement Agency (FEMA), the Transportation Security Agency (TSA), theNational Oceanic and Atmospheric Agency (NOAA), etc. The EAS source 2may be connected to the service provider 4 by any appropriatetransmission medium e.g., wired or wireless communication link, or viathe Internet. This connection between the EAS source 2 and the serviceprovider 4 may be such that EAS messages may be sent from the EAS source2 to the service provider 4.

The service provider 4 may be a provider of multimedia content andservices related to that multimedia content. Examples of the serviceprovider 4 include digital radio providers, analog radio providers,digital television providers, analog television providers, cabletelevision providers, satellite television providers, Internet Protocoltelevision providers, etc. The service provider 4 may be connected to aserver 6 by any appropriate transmission medium e.g., a wired orwireless communication link, the Internet, a cable or satellitetelevision network. This connection between the service provider 4 andthe server 6 may be such that data (e.g., multimedia content, an EASmessage, etc.) may be sent from the service provider 4 to the server 6.For example, the service provider 4 may be configured to use MPEGtransport streams to deliver video, audio, and/or data entertainmentservices to the server 6 (e.g., via a broadband network).

As described in more detail below, the server 6 may be configured toprocess some or all of the information received by it from the serviceproviders 4. For example, the server 6 may be configured to receive anddecode in-band data received from the service providers. Example servers6 include personal computer platforms or home communication terminals(such as set-top boxes, routers, etc.) which may include storage (suchas an integrated hard disk). The server 6 may be connected to each of aplurality of client devices 10 by any appropriate transmission medium,e.g., a wired or wireless communication link, e.g., Wi-Fi. Theconnection between the server 6 and a client device 10 may be such thatdata (e.g., multimedia content, an EAS message, etc.) may be sent fromthe server 6 to the client device 10. Furthermore, the connectionbetween the server 6 and a client device 10 may be such that data may besent from that client device 10 to the server 6, as described in moredetail below.

In other words, the server 6 may be a Digital Media Server (DMS) whichmay be configured to store content and make it available to clientdevices 10, which may be networked digital media players/renderers.

In certain embodiments, the server 6 is a Universal Plug and Play (UPnP)media server (MS). Further information on UPnP may be found, forexample, in the UPnP Device Architecture 1.1, Oct. 15, 2008, and onwww.upnp.org, which are incorporated herein by reference. However, inother embodiments the server 6 is not a UPnP server.

In an example, as depicted in FIG. 1, the server 6 includes a ContentDirectory Service (CDS) 8. The CDS 8 may include a dynamic, hierarchicalstructure of digital storage containers, each of which may be capable ofstoring digital data objects. A digital data object may include anobject description, an object content, and/or an object content locator(such as a Uniform Resource Locator (URL)).

This CDS 8 may provide a mechanism for devices (e.g., client devices 10)to obtain detailed information about the features supported by the CDS8, e.g., a “feature list”, that can inform client devices that the CDS 8supports an EAS message feature.

This CDS 8 may provide a uniform mechanism for devices (e.g., clientdevices 10) to browse the content on the server 6 and to obtain detailedinformation about individual content objects. The CDS 8 may additionallyprovide a lookup/storage service that allows devices to locate (andpossibly store) individual objects that the server 6 is capable ofproviding.

In some embodiments, the CDS 8 is a Universal Plug and Play (UPnP)Content Directory Service. Further information on UPnP Content DirectoryServices may be found, for example, in Content Directory:2 ServiceTemplate Version 1.01 For UPnP Version 1.0, May 31, 2006, and ContentDirectory: 3 Service Template Version 1.01 For UPnP Version 1.0, Sep.20, 2007, Version 0.17, and on www.upnp.org, which are incorporatedherein by reference. However, in other embodiments the CDS 8 is not aUPnP CDS.

Each client device 10 may be configured to process information receivedfrom the server 6. For example, each client device 10 may be configuredto render information received by it from the server 6 so that thatinformation may be consumed by a user 12 of that client device 10. Forexample, a client device may be configured to process and display (e.g.,on an integrated display) information (e.g., multimedia content, EASmessages, etc.) so that it may be consumed by the user 12. Exampleclient devices include televisions, audio amplifiers, computers (such asdesktop computers, laptop computers, tablet computers, smartphones,etc.), games consoles, wireless monitors, and other consumer electronicsdevices.

In an example, a client device 10 may be a Digital Media Player (DMP)and/or Digital Media Renderer (DMR). A client device 10 may beconfigured to find content on the server 6 and provide playback and/orrendering capabilities. A client device 10 may be configured to playcontent received from a digital media controller (DMC) which may havereceived content from the server 6.

In some embodiments, one or more of the client devices 10 may be aUniversal Plug and Play (UPnP) device. Also, in some embodiments, one ormore of the client devices 10 may be a device capable of implementingthe Multicast Domain Name Service protocol (mDNS) instead of or inaddition to being a UPnP device. For example, in other embodiments aclient device 10 may use the iOS mobile operating system (e.g., a clientdevice 10 may be an Apple™ iPod™, iPhone™, or iPad™ device).

The server 6 and the client devices 10 may be part of a residentiallocal area network (LAN), i.e., a home network. For example, the server6 and the client devices 10 may be parts of the user's home network. Forexample, server 6 and the client devices 10 may be located in the homeof the user 12.

FIG. 2 is a process flow chart showing an embodiment of a method ofpreparing the CDS 8 contained in the server 6 to provide a client device10 with a notification that a new EAS message has been received by theserver 6. In this embodiment, the server 6 is a UPnP server. The processof FIG. 2 may, for example, be performed by the CDS 8 upon booting ofthe server 6 and after initialisation of a UPnP stack of the server 6.The process of FIG. 2 may, for example, be performed by the CDS 8 whilstbuilding the feature list of the CDS 8.

At s2, the CDS 8 may construct a digital storage container forcontaining digital data objects relating to EAS messages. Thisconstructed container will hereinafter referred to as the “EAS contentcontainer”.

At s4, the CDS 8 may add, to its feature list (i.e., to a list ofoptional features and services that the CDS 8 provides in addition to orrelated to the individual content objects that may be provided by and/orstored on the server 6), an advertisement or feature that specifies thatdigital data objects relating to EAS messages may be provided by and/orstored on the server 6. Such a feature is hereinafter referred to as the“EAS feature advertisement”. The EAS feature advertisement may includean identifier for the EAS content container. The EAS featureadvertisement may include a URL that may be used (as described in moredetail later below with reference to FIGS. 3 and 4) by a client device10 to subscribe to a service that notifies that client device 10 of newEAS messages that are received by the server 6. This URL is hereinafterreferred to as the “EAS subscription URL”. In other embodiments, the EASfeature advertisement may include the EAS content container ID and notthe EAS subscription URL. In this case, a standard service eventsubscription URL may be used by client devices to request EAS serviceupdates.

At s5, optionally the CDS 8 may advertise itself to the client devices10 connected to the home network, e.g., by multicasting a message on thehome network. This may enable client devices 10 to “discover” the server6. However, the client devices 10 may discover the server 6 in adifferent way, e.g., by sending discovery messages as described in moredetails later below with reference to FIG. 3.

Thus, a method by which the CDS 8 may prepare to provide EAS featuresupport is provided.

FIG. 3 is a process flow chart showing an embodiment of a method bywhich a client device 10 may subscribe to a service that notifies thatclient device 10 that new EAS messages have been or are being receivedby the server 6. The process of FIG. 3 is described below as beingperformed by a single client device 10 (referred to in the descriptionof the process as “the client device 10”). However, in operation, theprocess of FIG. 3 may be performed by one or more (e.g., all) of theclient devices 10. In this embodiment, the client device 10 may be aDLNA compliant UPnP device.

The process of FIG. 3 may be performed, for example, after havingperformed the process of FIG. 2.

At s6, the client device 10 may transmit a discovery message to theserver 6 to determine whether a CDS 8 is supported by the server 6. Thismay be performed by, the client device 10 multicasting a UPnP discoverymessage, i.e., the client device 10 delivering a discovery message tothe group of destination computers to which it is connected.Multicasting the UPnP discovery message tends to be an efficient way todistribute this message. The multicast UPnP discovery message may bedelivered simultaneously in a single transmission from the client device10 to each of the entities with which the client device 10 is connected.The multicast UPnP discovery message is for discovery of the CDS 8.

At s8, the server 6 may receive the discovery message.

At s10, in response to receiving the discovery message, the server 6 maysend, to the client device 10, a service advertisement, i.e., a messagespecifying that the CDS 8 is available to provide information to theclient device 10. This service advertisement may be sent from the server6 to the client device 10 as a unicast message.

At s12, the client device 10 may receive the service advertisement.Using the received service advertisement the client device 10 determinesthat the CDS 8 is available to provide information to the client device10. In other words, the client device 10 “discovers” the CDS 8.

At s14, in response to receiving the service advertisement, the clientdevice 10 may send, to the CDS 8, a request for the feature list of theCDS 8. This request may be sent from the client device 10 to the CDS 8as a unicast message.

At s16, the CDS 8 may receive the request for its feature list.

At s18, in response to receiving the request for its feature list, theCDS 8 may send (e.g., as a unicast message) its feature list to theclient device 10. As described in more detail above with reference tos4, in this embodiment the feature list of the CDS 8 may include an EASfeature advertisement. The EAS feature advertisement may include anidentifier for the EAS content container.

At s20, the client device 10 may receive and process the feature list.This processing may include the client device 10 extracting, from thereceived feature list of the CDS 8, an identifier for the EAS messagecontainer that is included in the EAS feature advertisement of thefeature list.

At s22, the client device 10 may store (e.g., using a storage deviceintegrated win the client device 10), the extracted identifier for theEAS message container.

At s24, the client device 10 may send (e.g., as a unicast message) orpost, to the EAS subscription URL extracted at s20, a request tosubscribe to the service that notifies the client device 10 of new EASmessages that are received by the server 6. This request is hereinafterreferred to as the “EAS subscription request”.

At s26, in response to the client device 10 posting the EAS subscriptionrequest, the CDS 8 may generate a universally unique identifier (UUID)for the client device 10.

At s28, the CDS 8 may save/store (e.g., usmg a storage device integratedwin the server 6) the subscription information for the client device 10.This subscription information may include the subscription UUID for theclient device 10 (determined at s26) and information specifying whatservice(s) the client device has subscribed to (i.e., the service thatnotifies the client device 10 of new EAS messages that are received bythe server 6).

At s30, the CDS may send the subscription UUID (e.g., as a unicastmessage) for the client device 10 (determined at s26) to the clientdevice 10.

At s32, the client device 10 may store (e.g., using a storage deviceintegrated win the client device 10), the received subscription UUID.Thus, the client device 10 is subscribed to a service that notifies thatclient device 10 that new EAS messages have been or are being receivedby the server 6.

FIG. 4 is a process flow chart showing an embodiment of a process bywhich a new EAS message may be received by the server 6, and by whichclient devices 10 (which has subscribed to a service that notifies themthat new EAS messages have been or are being received by the server 6)may be notified that a new EAS message has been received by the server6. In this embodiment, the client device 10 may be a UPnP device.

The process of FIG. 4 may be performed, for example, after havingperformed the process of FIG. 3.

At s34, the EAS source 2 may send an EAS message to the service provider4. The EAS message may be sent from the EAS source 2 to the serviceprovider 4 in any appropriate format and via any appropriatetransmission medium.

At s36, the service provider 4 may receive the EAS message from the EASsource 2.

At s38, the service provider 4 may process the received EAS message.This may be performed to convert the received EAS message into adifferent format, such as a SCTE-18 format, or generate an SCTE-18message corresponding to the received EAS message. The SCTE-18 format(also known as ANSI J-STD-042) is a standard specified by the Society ofCable Telecommunications Engineers (SCTE). Further information on theSCTE-18 Standard may be found, for example, in Society of CableTelecommunications Engineers, Engineering Committee, Digital VideoSubcommittee, American National Standard, ANSI/SCTE 18 2007, EmergencyAlert Messaging for Cable, which is incorporated herein by reference.

The processing performed at s38 may, for example, be performed using aSCTE-18 Generator.

Thus an EAS message in SCTE-18 format may be produced.

At s40, the EAS message (that may be in a SCTE-18 format) may bedelivered from the service provider 4 to the server 6. The EAS messagemay be delivered from the service provider 4 to the server 6 using anyappropriate transmission medium and any appropriate transmission method.In an example delivery method, an SCTE-18 Generator of the serviceprovider 4 may transmit the EAS message (in SCTE-18 format), e.g., usingIP multicast packets, to a Cable Modem Termination System (CMTS) of theservice provider 4. The EAS message (in SCTE-18 format) may then bedelivered in a DSG™ Internet Protocol (IP) stream from the CMTS to theserver 6. In another example delivery method, the EAS message (inSCTE-18 format) may be delivered to the server 6 in a Data Over CableService Interface Specification (DOCSIS) IP stream. In another exampledelivery method, an SCTE-18 Generator of the service provider 4 maytransmit the EAS message (in SCTE-18 format), e.g., using IP multicastpackets, to an out-of-band modulator (OM) of the service provider 4. TheEAS message (in SCTE-18 format) may then be delivered in a QuadraturePhase Shift Keying (QPSK) out-of-band (OOB) stream from the OM to theserver 6.

At s42, the server 6 may receive the EAS message m the correspondingformat (e.g., in SCTE-18 format).

At s44, the server 6 may process the received EAS message. This may beperformed to convert the received EAS message from the first format,e.g., SCTE-18 format into a second format, e.g., SCTE-162 format.Similarly, the received EAS messages may be converted from SCTE-18format into the CEA-2035 or the ATIS 0800012 format. The SCTE-162 format(also known as ANSI J-STD-070/DVS-847 [SCTE-EAS], and also available asATIS-0800012) is a standard specified by the Society of CableTelecommunications Engineers (SCTE). Further information on the SCTE-162Standard may be found, for example, in Society of CableTelecommunications Engineers, Engineering Committee, Digital VideoSubcommittee, American National Standard, ANSI/SCTE 162 2009, EmergencyAlert Signaling for the Home Network, which is incorporated herein byreference. The translation of the EAS message from SCTE-18 format toSCTE-162 format may provide that the EAS message is translated (by theserver 6 hosting the CDS 8) to a format suitable for distribution on thehome network to the client devices 10. In other embodiments, a differentformat other than SCTE-162 may be used.

This processing may be performed using any appropriate translationmethod for translating the message in the first format to a message inthe second format, e.g., translating a SCTE-18 EAS message to a SCTE-162EAS message.

The translation of the EAS message from the SCTE-18 format to theSCTE-162 format may result in an Extensible Markup Language (XML)document representing the EAS event being generated.

In some embodiments, EAS messages may be delivered from the serviceprovider 4 to the server 6 via IP multicast from the service provider 4.In such embodiments, the EAS message may be repackaged from IP multicastfor distribution to the client devices 10 on the home network. Thedelivery of the message using IP multicast, and in a format that issuitable for distribution on the home network, may provide that this maybe performed without performing message format translation.

Optionally and additionally, the processing performed by the server 6 ats44 may further include determining whether or not the EAS is“applicable” or “relevant”. For example, the EAS message may bedetermined to be “not applicable” if the geographic region to which theEAS message relates is different to the geographic region of the server6 hosting the CDS 8. Also for example, the EAS message may be determinedto be “not applicable” if the EAS message is a “test message”. If theEAS message is determined to be “not applicable”, the message may bediscarded and the process of FIG. 4 may end.

At s46, the server 6 may store the generated XML document representingthe EAS event. This may be performed in an implementation-dependentmanner.

At s48, the server 6 may create a new EAS message object (i.e., adigital data objects relating to the EAS message). The created EASmessage object may include the XML document that may have been createdat s44. Alternatively, the created EAS message object may include a URLthat may be used to locate the XML document that may have been createdat s44.

At s50, the server 6 may add the new EAS message object created at s48to the EAS content container of the CDS 8. The new EAS message objectmay be added to objects stored previously in the EAS content container.Alternatively, the new EAS message may update objects stored previouslyin the EAS content container. Alternatively, the new EAS message mayoverride objects stored previously in the EAS content container.

At s52, the CDS 8 may generate a notification for each of the clientdevices 10 that have subscribed to the service that notifies them thatnew EAS messages have been or are being received by the server 6 (e.g.,using the process described above with reference to FIG. 3). Thenotifications generated may be notification that the server 6 hasreceived a new EAS message.

At s54, the CDS 8 may distribute (e.g., as a respective unicastmessage), to each of the client devices 10 that have subscribed to theservice that notifies them that new EAS messages have been or are beingreceived by the server 6, the notification generated for that clientdevice.

Thus, a process by which a new EAS message is received by the server 6,and by which client devices 10 (which has subscribed to a service thatnotifies them that new EAS messages have been or are being received bythe server 6) are notified that a new EAS message has been received bythe server 6 is provided.

FIG. 5 is a process flow chart showing an embodiment of a process bywhich a client device 10 may receive the EAS message, and display thatEAS message to the user 12 of that client device 10. The process of FIG.5 is described below as being performed by a single client device 10(referred to in the description of the process as “the client device10”). However, in operation, the process of FIG. 5 may be performed byone or more (e.g., all) of the client devices 10. In this embodiment,the client device 10 may be a UPnP device.

The process of FIG. 5 may be performed, for example, after havingperformed the process of FIG. 4.

At s56, the client device 10 may receive a notification that a new orupdated EAS message has been received by the server 6 (e.g., distributedto it from the server 6 at s54).

At s58, the client device may browse the CDS 8 (e.g., usmg anyappropriate software application for retrieving, presenting, andtraversing information resources on the CDS 8) for any EAS messageobject created at s48 and stored in the EAS content container of the CDS8 at s50. This may include the client device 10 sending (e.g., as aunicast message), to the CDS 8, a request that the contents of the EAScontent container be delivered to it.

At s60, the CDS 8 may send (e.g., as a unicast message) the EAS messageobject stored in the EAS content container to the client device 10.Alternatively, the client device 10 may retrieve the EAS message objectstored in the EAS content container in the CDS 8. At s62, the clientdevice 10 may receive the EAS message object.

At s64, the client device may process the received EAS message object.This may be performed to acquire (e.g., extract or retrieve) EAS messageinformation for display by the client device 10.

If, for example, the EAS message object includes the XML documentcreated at s44, the EAS message object may be processed to extract thisXML document. The XML document may then be processed to provide the EASmessage information in a format that may be displayed by the clientdevice 10. Alternatively, if, for example, the EAS message objectincludes a URL that may be used to locate the XML document created ats44, the EAS message object may be processed to extract this URL. TheURL may then be used by the client device to retrieve (e.g., from theserver 6 hosting the CDS 8 or another server via the Internet) the XMLdocument created at s44. This XML document may then be processed toprovide the EAS message information in a format that may be displayed bythe client device 10.

At s66, the client device 10 displays (e.g., on an integrated display)the EAS message for consumption the user 12 of that client device 10.

Thus, a process by which a client device 10 may receive the EAS message,and display that EAS message to the user 12 of that client device 10 isprovided.

FIG. 6 is a process flow chart showing an embodiment of a method ofpreparing a media server 6 to provide a client device 10 with anotification that a new EAS message has been received by the server 6.

The process of FIG. 6 may, for example, be performed by the server 6 ifa client device 10 cannot receive emergency alerts from digital mediaservers using UPnP. In this embodiment, the client devices 10 may beconfigured to implement mDNS (e.g., a client device 10 may support theiOS mobile operating system). Also for example, the process of FIG. 6may be performed by a media server 6 that supports mDNS instead of UPnP(i.e., a server that supports mDNS and not UPnP).

At s200, the server 6 may construct a Domain Name Service with ServiceDiscovery (DNS-SD) service for an Emergency Alert System (EAS). This maybe performed by adding appropriate pointer DNS (PTR) and Service locator(SRV) records to its list of supported services. This may be performedas described in “DNS-Based Service Discovery”, Document:draft-cheshire-dnsext-dns-sd-06.txt, Internet-Draft, Category: StandardsTrack, Stuart Cheshire, Marc Krochmal, 8 Mar. 2010, and www.ietf.org,which is incorporated herein by reference.

At s202, the server 6 may advertise the mDNS EAS message service usingany appropriate method, such as any of those described in the abovementioned “DNS-Based Service Discovery”.

Thus, a method by which the server 6 may prepare to provide EAS featuresupport is provided.

FIG. 7 is a process flow chart showing an embodiment of a method bywhich a client device 10 may discover the server 6 and request to benotified when the server 6 receives an EAS message, or an update to anEAS message. The process of FIG. 7 is described below as being performedby a single client device 10 (referred to in the description of theprocess as “the client device 10”). However, in operation, the processof FIG. 7 may be performed by one or more (e.g., all) of the clientdevices 10. In this embodiment, the client device may be device thatuses the iOS mobile operating system, or another operating system thatuses the Multicast Domain Name Service (mDNS) with Service Discovery(DNS-SD) extension.

The process of FIG. 7 may be performed, for example, after havingperformed the process of FIG. 6.

At s68, the client device may transmit a discovery message to the server6. This may be performed by, the client device 10 multicasting aMulticast Domain Name System (mDNS) service discovery message, i.e., theclient device 10 delivering an mDNS service lookup request for an EASmessage service to the group of destination computers to which it isconnected. Multicasting the discovery message tends to be an efficientway to distribute this message. In this embodiment, the client devicemay search for a device that supports an EAS message delivery servicethrough the use of mDNS.

At s70, the server 6 may receive the mDNS message.

At s72, in response to receiving the mDNS discovery message, the server6 may send, to the client device 10, a service address. The serviceaddress may, for example, be an IP address of the server 6. A servername may also be sent to the client device 10 (e.g., for displaypurposes). This server name may be provided in accordance with mDNSnaming conventions.

At s74, the client device 10 may receive the service address from theserver 6.

At s76, the client device 10 may update its mDNS cache using theinformation from the server 6. The client device may store (e.g., on anintegrated storage device) the IP address of the server 6.

Thus, in this embodiment a Domain Name System based Service Discovery(DNS-SD) process may be performed.

At s78, the client device 10 may send (e.g., as a unicast message) a DNSLong Lived Query request to the server 6. This DNS Long Lived Query maybe a request that the client device 10 shall be sent (by the server 6)new or updated EAS messages received by the server 6. Furtherinformation about DNS Long Lived Queries, DNS Long Lived Query requests,and the DNS Long Lived Query protocol may be found, for example, in “DNSLong-Lived Queries”, Document: draft-sekar-dns-llq-01.txt,Internet-Draft, Category: Standards Track, Stuart Cheshire, MarcKrochmal, Kiren Sekar, 10 Aug. 2006, and a www.ietf.org, which isincorporated herein by reference.

The “query type” of the DNS Long Lived Query request may be set to“text” (i.e., TXT). Thus, the client device 10, in effect, requests toreceive (from the server 6) EAS messages (or updates to EAS messages)represented by the text records of the server 6. A text record relatingto an EAS message may include (e.g., in text form) that EAS message or aURL for a file containing that EAS message.

At s79, the server 6 may receive the DNS Long Lived Query request. Thehandling of DNS Long-Lived Query requests by the server 6 may complywith the protocol and message exchanges described in the above mentioned“DNS Long-Lived Queries”.

At s80, in response to receiving the DNS Long Lived Query request, theserver 6 may send, to the client device 10, a “query identifierchallenge”. This challenge message may include information about anyerror(s) in the DNS Long Lived Query request sent to the server 6 fromthe client device 10. The challenge message may further include uniqueidentifiers for successful DNS Long Lived Query requests. Furtherinformation about the challenge message may be found in “DNS Long-LivedQueries”, Document: draft-sekar-dns-llq-01.txt, Internet-Draft,Category: Standards Track, Stuart Cheshire, Marc Krochmal, Kiren Sekar,10 Aug. 2006, and a www.ietf.org, which is incorporated herein byreference.

At s81, the client device 10 may receive the query identifier challenge.

At s82, in response to receiving the query identifier challenge from theserver 6, the client device 10 may return the query identifier challengeto the server 6. Thus, the client device 10 may “echo” the uniqueidentifier(s) for the successful DNS Long Lived Query requests back tothe server 6. Thus, the client device 10 demonstrates its reachabilityand willingness to participate to the server 6. Further informationabout the challenge response may be found in “DNS Long-Lived Queries”,Document: draft-sekar-dns-llq-01.txt, Internet-Draft, Category:Standards Track, Stuart Cheshire, Marc Krochmal, Kiren Sekar, 10 Aug.2006, and a www.ietf.org, which is incorporated herein by reference.

At s83, the server 6 may receive the query identifier challenge.

At s84, in response to receiving back the query identifier challenge,the server 6 may complete the set-up for the DNS Long Lived Query forthe client device 10.

At s86, the server 6 may send (e.g., as a unicast message) an initialquery response to the client device 10. The initial query response mayinclude any appropriate information. For example, if the server 6 hasreceived, from the service provider 4, an EAS message prior to theclient device 10 discovering the server 6 (e.g., prior to the clientdevice 10 joining the home network), the initial query response mayinclude TXT records for the EAS message already received.

Thus, a method by which a client device 10 may discover the server 6 andrequest to be notified when the server 6 receives an EAS message, or anupdate to an EAS message is provided.

FIG. 8 is a process flow chart showing an embodiment of a process bywhich a new EAS message may be received by the server 6, and by whichclient devices 10 may be notified that a new EAS message has beenreceived by the server 6.

The process of FIG. 8 may be performed, for example, after havingperformed the process of FIG. 6 and/or FIG. 7.

At s204, the EAS source 2 may send an EAS message to the serviceprovider 4. The EAS message may be sent from the EAS source 2 to theservice provider 4 in any appropriate format and via any appropriatetransmission medium.

At s206, the service provider 4 may receive the EAS message from the EASsource 2.

At s208, the service provider 4 may process the received EAS message.This may be performed to convert the received EAS message into SCTE-18format, or generate an SCTE-18 message corresponding to the received EASmessage e.g., as described in more detail earlier above with referenceto s38 of the process of FIG. 4.

At s210, the EAS message (e.g., in SCTE-18 format) may be delivered fromthe service provider 4 to the server 6. The EAS message may be deliveredfrom the service provider 4 to the server 6 using any appropriatetransmission medium and any appropriate transmission method.

At s212, the server 6 may receive the EAS message (e.g., in SCTE-18format).

At s214, the server 6 may process the received EAS message. This may beperformed to convert the received EAS message e.g., to convert the EASmessage from SCTE-18 format into SCTE-162 format e.g., as described inmore detail earlier above with reference to s44 of the process of FIG.4.

At s216, the server 6 may store the generated XML document representingthe EAS event. This may be performed in an implementation-dependentmanner.

At s218, the server may represent the EAS message using a DNS-SD textrecord. This may be performed using any appropriate method, such as anyof those described in the above mentioned “DNS-Based Service Discovery”.

At s220, the server 6 may add the DNS-SD text record to the EAS messageservice (that may have been defined as described above with reference toFIG. 6).

At s222, the server 6 may generate a notification for each of the clientdevices 10 that have (e.g., using the process of FIG. 7) requested to benotified when the server 6 receives an EAS message, or an update to anEAS message.

At s224, the server 6 may distribute (e.g., as a respective unicastmessage), to each of the client devices 10 that have requested to benotified when the server 6 receives an EAS message, or an update to anEAS message, the notification generated for that client device.

Thus, a process by which a new EAS message is received by the server 6,and by which client devices 10 may be notified is provided.

FIGS. 9A and 9B are process flow charts showing an embodiment of aprocess by which a new or updated EAS message may be received by theserver 6, acquired by a client device 10, and displayed to the user 12of that client device 10. The process of FIGS. 9A and 9B is describedbelow as being performed by a single client device 10 (referred to inthe description of the process as “the client device 10”). However, inoperation, the process of FIGS. 9A and 9B may be performed by one ormore (e.g., all) of the client devices 10. In this embodiment, theclient device may be configured to implement mDNS. For example, theclient device may be a device that uses the iOS mobile operating system.

The process of FIGS. 9A and 9B may be performed, for example, afterhaving performed the process of FIG. 7.

At s88 the EAS source 2 may send an EAS message to the service provider4. The EAS message may be sent from the EAS source 2 to the serviceprovider 4 in any appropriate format and via any appropriatetransmission medium.

At s90, the service provider 4 may receive the EAS message from the EASsource 2.

At s92, the service provider 4 may process the received EAS messageprior to it being transmitted to the server 6. This may be performed,for example, in the same way as that described above at s38 of FIG. 4.

At s94, the EAS message may be delivered from the service provider 4 tothe server 6. The EAS message may be delivered from the service provider4 to the server 6 using any appropriate transmission medium and anyappropriate transmission method. The EAS message may be delivered in anyappropriate format.

At s96, the server 6 may receive the EAS message.

At s97, the server 6 may process the received EAS message. This may, forexample, be performed as follows.

Firstly, the server 6 may translate the received EAS message from thereceived format (e.g., SCTE-18) to home network format (e.g., SCTE-162).This may, for example, be performed as described above with reference tos44 of the process of FIG. 4.

If the EAS message is a new message, the server 6 may then add thetranslated message to an XML document containing active alert messages.Thus, a new EAS message file may be created. The server 6 may then addfield(s) in the TXT resource record containing the URL pointing toactive alert message XML document.

Alternatively, if the EAS message is not a new message, but is anupdated existing message, the server 6 may then update the XML documentcontaining active alert messages. Thus, an EAS message file may beupdated. The server 6 may then update field(s) in the TXT resourcerecord containing the URL pointing to active alert message XML document.

Alternatively, if the EAS message is a duplicate message, the messagemay be discarded by the server 6, and the process of FIGS. 9A and 9B mayend.

At s98, the server 6 may distribute (e.g., as one or more unicastmessages) DNS Long Lived Query results to each client device 10 that hasposted a DNS Long Lived Queries with the server 6. Thus, the server 6may send, to a client device 10 that posted a DNS Long Lived Query, textresource records relating to the received new or updated EAS message.

At s100, the client device 10 may receive the DNS Long Lived Queryresult.

At s102, the client device 10 may examine or process the received DNSLong Lived Query result. For example, the client device 10 may examinethe received text resource record. This may be performed to determine ifthe DNS Long Lived Query result indicates that a new EAS message hasbeen received by the server 6.

The client device 10 may determine whether an EAS message is a newmessage in accordance with requirements of the EAS protocol being usedon the network 1 (e.g., in accordance with SCTE-18). In otherembodiments, a different appropriate way of differentiating between newand old (e.g., duplicate) messages may be used.

If at s102, it is determined that the DNS Long Lived Query resultindicates that the EAS message that has been received by the server 6 isa new EAS message, the method proceeds to s104. However, if at s102, itis determined that the DNS Long Lived Query result indicates that theEAS message that has been received by the server 6 is not a new EASmessage, the method proceeds to s112. s112 will be described in moredetail later below after the description of s104 to s110.

At s104, the client device 10 may determine whether or not it is alreadydisplaying (e.g., on an integrated display) an (e.g., older) EASmessage.

If at s104, it is determined that the client device 10 is alreadydisplaying an EAS message, the method proceeds to s106. However, if ats104, it is determined that the client device 10 is not alreadydisplaying an EAS message, the method proceeds to s108.

At s106, the presentation (i.e., display) of the older EAS messagecurrently being displayed by the client device 10 may be stopped. Thatolder EAS message may then be discarded.

At s108, the client device 10 may process the received DNS Long LivedQuery result. The client device may do this to acquire (e.g., extract orretrieve) the new EAS message information for display by the clientdevice 10.

If, for example, the text resource record includes the new EAS message(in text form), the text resource record may be processed to extract thenew EAS message. Alternatively, if, for example, the text resourcerecord includes a URL that may be used to locate the new EAS message,the text resource record may be processed to extract this URL. The URLmay then be used by the client device to retrieve (e.g., from a furtherserver via the Internet) the new EAS message.

At s110, the client device 10 may display (e.g., on an integrateddisplay) the new EAS message for consumption the user 12 of that clientdevice 10.

After performing s110, the method of FIGS. 9A and 9B may end.

Returning now to the case where, at s102, it is determined that the DNSLong Lived Query result indicates that the EAS message that has beenreceived by the server 6 is not a new EAS message, at s112, the clientdevice 10 may further examine the received DNS Long Lived Query result.For example, the client device 10 may further examine the received textresource record. This may be performed to determine if the DNS LongLived Query result indicates that an updated EAS message has beenreceived by the server 6.

If at s112, it is determined that the DNS Long Lived Query resultindicates that the EAS message that has been received by the server 6 isan updated EAS message, the method proceeds to s114. However, if ats112, it is determined that the DNS Long Lived Query result indicatesthat the EAS message that has been received by the server 6 is not anupdated EAS message, the method proceeds to s120. s120 will be describedin more detail later below after the description of s114 to s118.

At s114, it may be determined by the client device 10 whether or not theremaining alert time is equal to or less than zero (i.e., whether or notthe remaining time for which the EAS message should be shown is equal toor less than zero). Any appropriate method of specifying an amount ofalert time may be used. For example, a text resource record for an EASmessage may specify a date/time beyond which the EAS message should notbe displayed. In the case that the text resource record for an EASmessage contains a URL that may be used to retrieve an EAS message,including alert time information in the text resource record for an EASmessage may allow the client device 10 to determine whether or not itneeds to retrieve the actual EAS message. Thus, a client device 10 mayavoid fetching a message file that is not needed. In the case of an EASmessage that requires no action from the client device 10 (exceptperhaps to update the alert time remaining), the client device 10 mayget the information it needs from the text resource record (i.e., theevent notification).

If at s114, it is determined that the remaining alert time is equal toor less than zero, the method proceeds to s116. However, if at s112, itis determined that the remaining alert time is not equal to or less thanzero (i.e., is greater than zero), the method proceeds to s118.

At s116, the presentation (i.e., display) of the EAS message currentlybeing displayed by the client device 10 may be stopped. That EAS messagemay then be discarded.

After performing s116, the method of FIGS. 9A and 9B may end.

At s118, the EAS message currently being displayed by the client device10 may be updated. This may be performed using an updated messagespecified in the text resource record for the EAS message, or retrievedusing a URL specified in the text resource record for the EAS message.

After performing s118, the method of FIGS. 9A and 9B may end.

Returning now to the case where, at s112, it is determined that the DNSLong Lived Query result indicates that the EAS message that has beenreceived by the server 6 is not an updated EAS message, at s120 thereceived DNS Long Lived Query (e.g., the received text resource record)may be discarded. This may be performed because it may be determinedthat the EAS message received by the server 6 is a duplicate message.

After performing s120, the method of FIGS. 9A and 9B may end.

Thus, a process by which a new or updated EAS message may be received bythe server 6, acquired by a client device 10, and displayed to the user12 of that client device 10 is provided.

The systems and methods disclosed herein may enable the delivery ofSCTE-18 EAS messages from a UPnP server device to UPnP client devicese.g., in a home network. Furthermore, the systems and methods disclosedherein may provide a manner for delivering delivery EAS messages toclient devices that support mDNS

Furthermore, the systems and methods disclosed herein for processing EASmessages may reduce or minimize the duplication of messages for EASsupport.

The server (which may offer services such as the live broadcast ofmultimedia content from one or more sources) may advertise support forEAS message distribution. Furthermore, the server may provide suchadvertisements to clients in the home network. Furthermore, the servermay distribute EAS messages to client devices in the home network. Thismay be performed with minimal delay. Furthermore, the server may providereferences to channel and audio alert resources, and map these resourcesto local URLs which the server may resolve for the client devices.

Advertising of support for EAS message distribution by the server may beperformed through service description. Advertising of support for EASmessage distribution by the server may be performed through containerpresence. Advertising of support for EAS message distribution by theserver may be in CDS feature list. Thus, advertising may use existing,standard CDS capability. Furthermore, client devices may be directlyinformed of the presence of the feature. Furthermore, client devices maybe directly provided with an identifier for the emergency alert messagecontainer. Furthermore, client devices may be provided with otherfeature support, such as a dedicated event subscription URL. Advertisingof support for EAS message distribution by the server may be provided asan mDNS service. Thus, the techniques disclosed herein may providesupport for devices that are not compliant with Digital Living NetworkAlliance (DLNA) requirements, and may provide support for iOS devicesthat are otherwise not supported by current techniques.

Using above described methods, UPnP client devices may locate a serveron the home network that supports the EAS message feature. A UPnP CDSmay provide EAS support.

Above described system and methods may provide for the conversion of EASmessaging from one format (e.g., SCTE-18), by the device hosting the CDS(i.e., the server), to a format suitable for distribution on the homenetwork client devices (e.g., SCTE-162).

Above described system and methods may provide for (e.g., if EASmessages are delivered by IP multicast from a head-end server) therepackaging of the EAS messages for distribution to client devices onthe home network.

The client devices may be capable of independently evaluating allmessage criteria to determine whether a message is active; how topresent the alert message (text scroll, text scroll with audio, videodetails or deferred by exception channel list, and so on); and when amessage has expired.

The server and CDS disclosed herein may be capable of dealing with EASmessage expiration. For example, the CDS may monitor the duration ofeach active alert message. At message expiration, the CDS may delete themessage, e.g., regardless of how it is represented. The CDS may notgenerate event notifications upon message expiration. Client devices mayalso check for message expiration.

1. (canceled)
 2. A method for configuring a home network for emergencymessaging, the method comprising: receiving, by a home communicationsserver and from a client device, a discovery message in search of adevice that supports an emergency message service; transmitting, by thehome communications server and to the client device in response to thediscovery message, a response specifying that the home communicationsserver supports an emergency message service, the response including aservice address of the home communications server; receiving, by thehome communications server and from the client device, a request thatthe client device be notified that the home communications server hasreceived an emergency alert message, wherein the request includes theservice address of the home communications server; in response toreceiving the request, registering, by the home communications server,the client device as a device that will be transmitted notificationsregarding emergency alert messages received by the home communicationsserver; receiving, by the home communications server and from an entityremote from the home communications server, an emergency alert messagethat is broadcast in a first format; and transmitting, by the homecommunications server and to the client device, a notificationindicating that the home communications server has received an emergencyalert message based on the client device being registered to betransmitted the notifications, wherein the home communications serverand the client device are each part of the residential Local AreaNetwork.
 3. The method of claim 2, further comprising converting, by thehome communications server, the emergency alert message from the firstformat to a second format that is suitable for distribution to theclient device over a residential Local Area Network.
 4. The method ofclaim 3, further comprising: transmitting, by the home communicationsserver and to the client device, a query identifier challenge specifyingone or more unique identifiers corresponding to successful requests;receiving, by the home communications server and from the client device,a challenge response that includes the one or more unique identifiers,wherein: registering the client device as a device that will betransmitted notifications regarding emergency alert messages received bythe home communications server comprises registering the client inresponse to receiving the request and receiving the challenge responsethat includes the one or more unique identifiers that were transmittedby the home communications server; and wherein: the second format isdifferent from the first format; and the second format is an ExtensibleMarkup Language format.
 5. The method of claim 4, wherein the firstformat is compliant with an SCTE-18 standard and the second format iscompliant with an SCTE-162 standard.
 6. The method of claim 2, whereinthe emergency alert message is a national warning system message.
 7. Themethod of claim 2, wherein the notification comprises information thatthe client device uses to ascertain whether the emergency alert messageis a new emergency alert message, an updated emergency alert message, ora duplicate emergency alert message.
 8. The method of claim 2, furthercomprising providing, by the home communications server and to theclient device, the emergency alert message or a Universal ResourceLocator from which the emergency alert message is retrievable.
 9. Themethod of claim 2, wherein: the request is a Domain Name System LongLived Query request; and the emergency alert message or informationrelated to the emergency alert message is transmitted, by the homecommunications server and to the client device, as a Domain Name SystemLong Lived Query result.
 10. The method of claim 2, wherein the clientdevice communicates with the home communications server using aMulticast Domain Name Service protocol.
 11. A home communicationsserver, comprising: one or more communications components arranged tocommunicate with multiple client devices that are part of a sameresidential Local Area Network as the home communications server,wherein the communications devices include at least one of a wirelinecommunications interface or a wireless communications interface; a datastore storing data identifying a set of devices that will be transmittednotifications regarding emergency alert messages received by the homecommunications server; and one or more hardware processors arranged tointeract with the data store and the one or more communicationscomponents, the one or more hardware processors further arranged toconfigure a home network for emergency messaging by: transmitting, to aclient device and in response receiving a discovery message from theclient device, a message specifying that the home communications serversupports an emergency message service, the message including a serviceaddress of the home communications server; receiving, by the homecommunications server and from the client device, a request that theclient device be notified that the home communications server hasreceived an emergency alert message, wherein the request includes theservice address of the home communications server; in response toreceiving, from the client device, a request that (i) includes theservice address of the home communications server and (ii) requests thatthe client device be notified when the home communications server hasreceived an emergency alert message, registering the client device as adevice that will be transmitted notifications regarding emergency alertmessages received by the home communications server; and in response toreceiving, from an entity remote from the home communications server, anemergency alert message, transmitting, to the client device, anotification indicating that the home communications server has receivedan emergency alert message, wherein the transmitting occurs based on theclient device being registered to be transmitted the notifications, andwherein the home communications server and the client device are eachpart of the residential Local Area Network.
 12. The home communicationsserver of claim 11, further arranged to configure a home network foremergency messaging by converting the emergency alert message from afirst format to a second format that is suitable for distribution to theclient device over a residential Local Area Network.
 13. The homecommunications server of claim 12, further arranged to configure a homenetwork for emergency messaging by: transmitting, to the client device,a query identifier challenge specifying one or more unique identifierscorresponding to successful requests; receiving, from the client device,a challenge response that includes the one or more unique identifiers,wherein: registering the client device as a device that will betransmitted notifications regarding emergency alert messages received bythe home communications server comprises registering the client inresponse to receiving the request and receiving the challenge responsethat includes the one or more unique identifiers that were transmittedby the home communications server; and wherein: the second format isdifferent from the first format; and the second format is an ExtensibleMarkup Language format.
 14. The home communications server of claim 13,wherein the first format is compliant with an SCTE-18 standard and thesecond format is compliant with an SCTE-162 standard.
 15. The homecommunications server of claim 11, wherein the emergency alert messageis a national warning system message.
 16. The home communications serverof claim 11, wherein the notification comprises information that theclient device uses to ascertain whether the emergency alert message is anew emergency alert message, an updated emergency alert message, or aduplicate emergency alert message.
 17. The home communications server ofclaim 11, further arranged to configure a home network for emergencymessaging by providing, to the client device, the emergency alertmessage or a Universal Resource Locator from which the emergency alertmessage is retrievable.
 18. The home communications server of claim 11,wherein: the request is a Domain Name System Long Lived Query request;and the emergency alert message or information related to the emergencyalert message is transmitted, by the home communications server and tothe client device, as a Domain Name System Long Lived Query result. 19.The home communications server of claim 11, wherein the client devicecommunicates with the home communications server using a MulticastDomain Name Service protocol.
 20. A system, comprising: one or morecommunications components arranged to communicate with multiple clientdevices that are part of a same residential Local Area Network as thehome communications server, wherein the communications devices includeat least one of a wireline communications interface or a wirelesscommunications interface; one or more hardware processors arranged tointeract with the one or more communications components; and anon-transitory machine readable medium storing instructions that, uponexecution of the instructions by the one or more hardware processorscauses the one or more hardware processors to perform operationsincluding: transmitting, to a client device and in response receiving adiscovery message from the client device, a message specifying that thehome communications server supports an emergency message service, themessage including a service address of the home communications server;receiving, by the home communications server and from the client device,a request that the client device be notified that the homecommunications server has received an emergency alert message, whereinthe request includes the service address of the home communicationsserver; in response to receiving, from the client device, a request that(i) includes the service address of the home communications server and(ii) requests that the client device be notified when the homecommunications server has received an emergency alert message,registering the client device as a device that will be transmittednotifications regarding emergency alert messages received by the homecommunications server; and in response to receiving, from an entityremote from the home communications server, an emergency alert message,transmitting, to the client device, a notification indicating that thehome communications server has received an emergency alert message,wherein the transmitting occurs based on the client device beingregistered to be transmitted the notifications, and wherein the homecommunications server and the client device are each part of theresidential Local Area Network.
 21. The system of claim 20, wherein theinstructions cause the one or more hardware processors to performoperations including converting the emergency alert message from a firstformat to a second format that is suitable for distribution to theclient device over a residential Local Area Network.
 22. The system ofclaim 21, wherein the instructions cause the one or more hardwareprocessors to perform operations including: transmitting, to the clientdevice, a query identifier challenge specifying one or more uniqueidentifiers corresponding to successful requests; receiving, from theclient device, a challenge response that includes the one or more uniqueidentifiers, wherein: registering the client device as a device thatwill be transmitted notifications regarding emergency alert messagesreceived by the home communications server comprises registering theclient in response to receiving the request and receiving the challengeresponse that includes the one or more unique identifiers that weretransmitted by the home communications server; and wherein: the secondformat is different from the first format; and the second format is anExtensible Markup Language format.
 23. The system of claim 22, whereinthe first format is compliant with an SCTE-18 standard and the secondformat is compliant with an SCTE-162 standard.
 24. The system of claim20, wherein the emergency alert message is a national warning systemmessage.
 25. The system of claim 20, wherein the notification comprisesinformation that the client device uses to ascertain whether theemergency alert message is a new emergency alert message, an updatedemergency alert message, or a duplicate emergency alert message.
 26. Thesystem of claim 20, wherein the instructions cause the one or morehardware processors to perform operations including providing, to theclient device, the emergency alert message or a Universal ResourceLocator from which the emergency alert message is retrievable.
 27. Thesystem of claim 20, wherein: the request is a Domain Name System LongLived Query request; and the emergency alert message or informationrelated to the emergency alert message is transmitted, by the homecommunications server and to the client device, as a Domain Name SystemLong Lived Query result.
 28. The system of claim 20, wherein the clientdevice communicates with the system using a Multicast Domain NameService protocol.